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Beschreibung 

uberprtifung der Verftigbarkeit eines Servers 

Die vorliegende Erfindung betrif ft ein Verfahren zur Uberprti- 
fung der Verftigbarkeit eines Servers, ein Steuerungsprogramm 
und einen Client fur ein verbindungslose Dienste bereitstel- 
lendes Netz. 

Eine zuverlassige Uberprtifung der Verfugbarkeit eines Servers 
ist insbesondere bei lose gekoppelten Client-Server-Beziehun- 
gen in paketorientierten Datennetzen von groSer Bedeutung. 
Erkennt ein Client frtihzeitig, daS ein Server ttberlastet oder 
ausgef alien ist, so kSnnen noch rechtzeitig GegenmaSnahmen 
eingeleitet werden, beispielsweise Suche nach einem Alterna- 
tiv-Server oder Erzeugen von Warnhinweisen. Verfahren zur 
Uberprtifung der Verfugbarkeit eines Servers, zu denen auch im 
H. 323 -Standard, Stand 11/2000, Kap. 7.2.2 beschriebene Keep- 
Alive-Tests zahlen, werden angewendet, wenn keine permanente 
Kommunikationsbeziehung zwischen Client und Server besteht, 
ein fehlerfreies Bestehen einer solchen Beziehung jedoch 
Grundlage fur eine gewtinschte Funktionalitat ist, beispiels- 
weise Internet-Telephonie . In paketorientierten Netzen dienen 
Keep-Alive-Tests beispielsweise dazu, Kommunikationsteilneh- 
mern einen quasi leitungsvermittelnden Charakter hinsichtlich 
gegenseitiger Erreichbarkeit zu simulieren. 

Bei gangigen Keep-Alive-Tests sendet ein Client in zyklischen 
Zeitabstanden Verftigbarkeitsanf ragen an einen ausgewahlten 
Server. Wird eine Verftigbarkeitsanf rage durch den Server in- 
nerhalb eines vorgebbaren Zeitraums beantwortet, gilt der 
Server als verftigbar und die Kommunikationsbeziehung daher 
als aktiv. Nachteilig an dieser Vorgehensweise ist, da& der 
Server in der Regel durch eine Beantwortung samtlicher Cli- 
ent -Anf ragen erheblich belastet wird. 
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Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
ein Verfahren zur Uberprufung der Verftigbarkeit eines Serv- 
ers, das eine Minimierung der Belastung des Servers durch an 
ihn gerichtete Verftigbarkeitsanf ragen ermSglicht, sowie zur 
5 Durchftihrung des Verfahrens geeignete technische Implement ie- 
rungen anzugeben. 

Diese Aufgabe wird erf indungsgemeiS durch ein Verfahren mit 
den in Anspruch 1, ein Steuerungsprogramm mit den in Anspruch 
10 7 und einen Client mit den in Anspruch 8 angegebenen Merkma- 
len geldst, Vorteilhafte Weiterbildungen der vorliegenden Er- 
findung sind in den abhangigen Ansprtichen angegeben. 

Ein wesentlicher Aspekt der vorliegenden Erfindung besteht 
15 darin, daS ein Client, der auf eine an einen Server gerichte- 
te Verftigbarkeitsanf rage eine Bestatigungsmeldung vom Server 
empfangen hat, eine Meldung tiber die Verfugbarkeit des Serv- 
ers an weitere Clients tibermittelt. Daraufhin unterbinden die 
vorgebbaren weiteren Clients zumindest fur ein vorgebbares 
20 Zeitintervall ein Ubermitteln einer Verftigbarkeitsanf rage an 
den Server. Auf diese Weise kann die Belastung des Servers 
durch Verftigbarkeitsanf ragen erheblich reduziert werden, ohne 
dafi dies beispielsweise zu Lasten einer nicht mehr rechtzei- 
tigen Erkennung eines Serveraus falls oder einer Serveruberla- 
stung geht. 

Die vorliegende Erfindung wird nachfolgend an einem Ausftih- 
rungsbeispiel anhand der Zeichnung naher erlautert. Es zeigt 

30 Figur 1 ein Anwendungsxomf eld der vorliegenden Erfindung mit 
zahlreichen Clients und Servern in einem pake tor i- 
entierten Netz mit mehreren Teilnetzen, 




35 



Figur 2 ein Ablaufdiagramm fur ein Verfahren zur Uberpru- 
fung der Verftigbarkeit eines Servers, 
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Pigur 3 ein Ablauf diagramm fur ein gegentiber Pigur 2 modi- 
fiziertes Verfahren, bei dem zusatzlich die Verfiig- 
barkeit von Clients durch den Server uberprtift 
wird. 

5 

In Pigur 1 ist ein Kommunikationssystem dargestellt, das ein 
paketorientiertes Netz mit mehreren Teilnetzen 101, 110, 120, 
130, Server 102 bis 104 und mehrere Clients 111 bis 115, 121 
bis 123, 131 bis 133 umfafit. Die Clients 111 bis 115, 121 bis 
10 123, 131 bis 133 nutzen von den Servern 102 bis 104 angebote- 
ne Dienste, beispielsweise Internet-Telef onie . 

Bei den Teilnetzen 110, 120, 130 handelt es sich urn lokale 
Subnetze, die jeweils uber einen Gatekeeper verfttgen. Die Ga- 
15 tekeeper dienen vornehmlich zur Zugangskontrolle und zu 

AdreStibersetzungsdiensten. Diese Funk tionali tat der Gatekee- 
per kann durch Server im paketorientierten Netz ubernommen 
werden . 




20 Zur Nutzung von durch einen Server 102 bis 104 angebotenen 
Diensten registrieren sich die Clients 111 bis 115, 121 bis 
123, 131 bis 133 zunachst am jeweiligen Server. Dabei wird 
ein Zeitraum spezif iziert , innerhalb dessen eine Registrie- 
rung als giiltig behandelt wird. Der Ablauf eines Registrie- 

jyjm rungsverfahrens wird exemplarisch und ohne Beschrankung der 
Allgemeingultigkeit ftir den Client 111 dargestellt. 

Der Client 111 verfugt uber eine zentrale Prozessoreinheit 
(CPU) , einen Arbeitsspeicher (RAM) , eine Festplatte zur 
30 nichtf ltichtigen Speicherung von Daten (HD) , einen Netzwerk- 

adapter (Tx/Rx) und eine Zeitsteueriingseinheit (Timer) . Einen 
solchen Aufbau und eine solche Funktionalitat konnen auch die 
ubrigen in Figur 1 darges tell ten Clients 112 bis 115, 121 bis 
123, 131 bis 133 aufweisen. 

35 

Zur Regis trierung an einem der Server 102 bis 104 iibermittelt 
der Client 111 eine Meldung mit einer Regis trierungsanforde- 
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rung RRQ an einen Server, der einen gewiinschten Dienst be- 
reitstellt. In der Meldung mit der Registrierungsanf orderung 
RRQ wird ein Zeitraum spezif iziert , innerhalb dessen die Re- 
gistrierung des Clients 111 am ausgewahlten Server gultig 
5 sein soil. AuSerhalb dieses Zeitraums gilt die Registrierung 
des Clients als ungtiltig. 



Bei Verftigbarkeit antwortet der ausgewahlte Server durch eine 
Meldung mit Regis trierungsbes tat igung RCF auf die Registries 
10 rungsanf rage . In der Meldung mit der Registrierungsbestati- 
gung RCF ebenfalls einen Gtiltigkeitszeitraum ftir die Regi- 
strierung spezif iziert. Der vom ausgewahlten Server bestatig- 
te Gtiltigkeitszeitraum entspricht entweder dem vom Client 111 
angegebenen Zeitraum oder ist ktirzer als dieser. 

15 

Innerhalb des Gtiltigkeitszeitraums fur die Registrierung kann 
der Client 111 Verftigbarkeitsanf ragen an den ausgewahlten 
Server richten. Derartige Verfugbarkeitsanf ragen, die auch 
als Keep-Alive-Tests bezeichnet werden, werden ebenfalls in 
20 Form einer Meldung mit einer Regis trierungsanf rage RRQ an den 
ausgewahlten Server tibermittelt. Eine im Rahmen eines Keep- 
Alive-Tests tibermittelte Meldung mit Registrierungsanf rage 
RRQ weist gegentiber gewohnlichen Meldungen mit Registrie- 
rungsanf rage ein gesetztes Keep-Alive-Bit ist. 




Entsprechend den ITU-T-Empf ehlungen H. 225.0, Stand 11/2000, 
Kapitel 7.9 ist eine verktirzte Meldung mit Regis trierungsan- 
frage ftir eine "Lightweight Registration" bereits ausrei- 
chend. Dabei- weist die Meldung mit Registrierungsanf rage le- 
30 diglich Angaben tiber eine Regis trierungs- und Status- 

Transportadresse (RAS-Adresse) des Clients, ein gesetztes 
Keep-Alive-Bit, einen Endpunktidentif ikator fur den Client, 
einen Server- bzw. Gatekeeper ident if ikator , Berechtigungsmar- 
ken (Tokens) ftir auszuftihrende Operationen und einen Gtiltig- 
35 keitszeitraum ftir die Registrierung. 



200307837 



5 

Eine Meldung mit Registrierungsanf orderung RRQ, die im Rahmen 
eines Keep-Alive-Tests an den ausgewahlten Server ubermittelt 
wird, kann auch zur VerlSngerung des Gultigkeitszeitraums der 
Registrierung verwendet werden. Dies gilt jedoch nur dann, 
5 wenn die Meldung noch innerhalb des Giiltigkeitszeitraums der 
Registrierung vom ausgewahlten Server empfangen wird, Daher 
sollten zur Ermittlung des Endes eines Giiltigkeitszeitraums 
durch einen Client auch Meldungs- und Bearbeitungsverzogerun- 
gen berucksichtigt werden. Nach dem Ende des Gultigkeitszeit- 
10 raums der Registrierung ist zur erneuten Regis trierung eine 
Ubermittlung einer oben beschriebenen verkurzten Meldung mit 
Registrierungsanf rage nicht mehr ausreichend. 

Falls die Meldung mit der Registrierungsbestatigung RCF keine 
15 Angabe fiber einen Gultigkeitszeitraum der Registrierung auf- 
weist, wird dies dahingehend gewertet werden, dafi der ausge- 
wahlte Server keine Keep-Alive-Mechanismen ftir Verfugbar- 
keitsanfragen untersttitzt . Clients sollten bei Empfang einer 
solchen Meldung ohne Angabe liber einen Gaitigkeitszeitraiam 
20 ein Versenden von Verfiigbarkeitsanfragen an den jeweiligen 
Server unterbinden. 

Nach Ablauf der Gtiltigkeit einer Registrierung kann der aus- 
gewahlte Server eine Meldung mit einem entsprechenden Hinweis 
an den betroffenen Client ubermitteln, xim diesen uber den Ab- 
lauf des Gultigkeitszeitraums zu informieren. Dies ist insbe- 
sondere bei einem Verlust der Synchronisierung zwischen 
Zeitsteuerungseinheiten am Client einerseits und am Server 
andererseits von Vorteil. 

Sendet der Client 111 nach dem Ende des Gultigkeitszeitraums 
der Registrierung eine oben beschrieben verktirzte Meldung mit 
Registrierungsanfrage RRQ und gesetztem Keep-Alive-Bit an den 
ausgewahlten Server, so wird der Server durch eine Meldung 
mit Regis trierungszuruckweisung RRJ reagieren. In einer sol- 
chen Meldung kann auch ein Zuruckweisungsgrund angegeben 
sein. 
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Urn eine unnotige Belastung eines Servers 102 bis 104 durcli 
Verfiigbarkeitsanf ragen von Clients 111 bis 115 , 121 bis 123, 
131 bis 133 zu vermeiden, informiert ein Client, der eine po- 
sitive oder eine negative Antwort auf eine Verfiigbarkeitsan- 
frage erhalten hat, mittels einer Multicast-Meldung MCM samt- 
liche Clients innerhalb desselben Teilnetzes 110, 120, 130 
tiber die Verftigbarkeit des jeweiligen Servers. Durch eine Be- 
grenzung auf dasselbe Teilnetz konnen auBerdem Probleme im 
Hinblick auf nicht allgemein auflosbare Adressen umgangen 
werden. Insbesondere wird eine unnotige Netzbelastung durch 
nichtadressierbare Meldungen verhindert. 

Das in Figur 2 dargestellte Ablaufdiagramm dient zur weiteren 
Veranschaulichung eines Verfahrens zur Uberprtifung der Ver- 
ftigbarkeit eines Servers in einem paketorientierten Koramuni- 
kationsnetz . Ausgangspunkt des Verfahrens ist ein Start eines 
Timers bzw. eines Zahlers einer Zeitsteuerungseinheit eines 
Clients (Schritt 201) . Durch den Timer werden Zeitpunkte 
festgelegt, zu denen Verfiigbarkeitsanf ragen des Clients an 
einen ausgewahlten Server tibermittelt werden sollen. 

Nach dem Start des Timers iiberwacht der Client den Empfang 
von Multicast-Meldungen MCM, aus denen sich Aussagen tiber die 
Verftigbarkeit eines Servers ergeben (Schritt 202) . Empfangt 
der Client eine solche Multicast-Meldung, so wird der Timer 
zuriickgesetzt (Schritt 208). Dadurch wird eine Ubermittlung 
von Verfiigbarkeitsanf ragen an den ausgewahlten Server fur ein 
vorgebbares Zeitintervall unterbunden. 

Sofem keine.neue Multicast-Meldung empfangen wurde, wird zu- 
satzlich tiberprxift, ob der Timer abgelaufen \ind damit ein 
Zeitpunkt zum Absetzen einer neuen Verfiigbarkeitsanf rage er- 
reicht ist (Schritt 203) . Wenn der Timer noch nicht abgelau- 
fen ist, werden weiterhin der Empfang von Multicast-Meldungen 
und der Ablauf des Timers iiberpruf t . Ist der Timer abgelau- 



200307837 



7 

fen, wird eine Verftigbarkeitsanf rage an den ausgewahlten Ser- 
ver versendet (Schritt 204) . 

In Schritt 205 wird zumindest implizit die Verfttgbarkeit Oder 
Nichtverfugbarkeit des ausgewahlten Servers f estgestellt . 1st 
der ausgewahlte Server verftigbar, so antwortet dieser durch 
eine an den anfragenden Client gerichtete Bestatigungsmeldung 
auf die Verftigbarkeitsanf rage (Schritt 206) . Nach Erhalt der 
Bestatigungsm.eldung informiert der anfragende Client samtli- 
che weiteren Clients innerhalb desselben Teilnetzes tiber die 
Verfttgbarkeit des ausgewahlten Servers mittels einer Multi- 
cast-Meldung (Schritt 207). Daraufhin unterbinden die weite- 
ren Clients, welche die Multicast-Meldung empfangen haben, 
ihrerseits ein ttbermitteln von Verftigbarkeitsanf ragen an den 
ausgewahlten Server ftir ein vorgegebenes Zeitintervall . 

Da bei Ausfall oder Uberlastung des ausgewahlten Servers kei- 
ne Bestatigungsmeldung tiber dessen Verftigbarkeit versendet 
wird, wird tiberprtift, ob der ausgewahlte Server zumindest in 
der Lage ist, mit einer Nichtverftigbarkeitsmeldung auf die 
Verftigbarkeitsanf rage zu reagieren (Schritt 209), Bei einer 
Uberlastung des ausgewahlten Servers ware dies beispielsweise 
noch moglich. Dagegen ist bei einem Ausfall des ausgewahlten 
Servers nicht mehr mit einem Versenden einer Nichtverftigbar- 
keitsmeldung zu rechnen. Daher wird tiberprtift ob ein Zeitli- 
mit ftir den Empfang einer Bestatigungsmeldung oder einer 
Nichtverftigbarkeitsmeldung erreicht wird (Schritt 211) . Wird 
dieses Zeitlimit tiber schr it ten, so tibermittelt der anfragende 
Client eine Multicast-Meldung tiber die Nichtverftigbarkeit des 
ausgewahlten Servers an samtliche Clients innerhalb desselben 
Teilnetzes (Schritt 210) . In entsprechender Weise wird ver- 
fahren, wenn der anfragende Client innerhalb des ftir eine An- 
wort auf die Verftigbarkeitsanf rage zuiassigen Zeitlimits eine 
Nichtverftigbarkeitsmeldung erhalt. 

Das beschriebene Verfahren zur Uberprtifung der Verftigbarkeit 
eines Servers wird vorzugsweise durch ein Steuerungsprogramm 
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implementiert, das in einen Arbeitsspeicher eines Clients 
ladbar ist und zumindest einen Code-Abschnitt aufweist, bei 
dessen Ausfiihrung die vorangehend beschriebenen Schritte 
Ubermitteln der Verfugbarkeitsanfrage, Uberwachen des Emp- 
fangs einer Bestatigungsmeldung, Ubermitteln einer Meldung 
iiber die Verfugbarkeit an weitere Clients, Uberwachen des 
Empfangs von Meldungen weiterer Clients und ggf . Unterbinden 
des Versendens von Verfugbarkeitsanf ragen ablaufen. Mittels 
des Steuerungsprogramms wird ein Client fur ein verbindungs- 
lose Dienste bereitstellendes Kommunikationsnetz implemen- 
tiert, der eine Einrichtung zum Ubermitteln von Verfugbar- 
keitsanf ragen, eine Einrichtung zur Uberwachung des Empfangs 
von Bestatigungsmeldungen, eine Einrichtung zur Ubermittlung 
von Meldungen uber die Verftigbarkeit von Servern an weitere 
Clients sowie eine Einrichtung zur Uberwachung des Empfangs 
von Meldungen weiterer Clients und zum Unterbinden des Uber- 
mittelns von Verfugbarkeitsanf ragen aufweist. 

Die nachfolgenden Betrachtungen dienen einer Herleitung der 
Vorteile des beschriebenen Verfahrens zur Uberpriifung der 
Verftigbarkeit eines Servers gegentiber bisher gangigen Keep- 
Alive-Tests. Entsprechend den bisher gangigen Keep-Alive- 
Tests wurde ein Server bei n=1000 Verfugbarkeitsanf ragen sen- 
denden Clients und einer Anfragerate von a=3 Anfragen pro Mi- 
nute und Client sowie unter der Annahme einer zeitlichen 
Gleichverteilung derartiger Anfragen alle 

r r (a = 3,n = 1000) = — = 60s = 20ms 
a-n 3-1000 

eine Verfugbarkeitsanf rage zu beantworten haben. 

Der Server ware also durchschnittlich alle 20 ms damit be- 
schaftigt, eine Verfugbarkeitsanfrage zeitnah zu beantworten. 
Dies wurde zu einer erheblichen Belastung des Servers durch 
Verfugbarkeitsanf ragen ftihren, was ihn in der Wahrnehmung 
seiner ihm eigentlich zugedachten Aufgaben stark einschranken 
wurde. Zur Losung dieses Problems wurde sich zunachst anbie- 
ten, die Anfragerate der Clients pro Minute stark zu reduzie- 
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ren, was jedoch zur Folge hatte, daS die betroffenen Clients 
den Verlust der Verfttgbarkeit des Server unter Umstanden un- 
zureichend spat feststellen. 

5 Fur eine Abschatzung einer mit dem hier vorgeschlagenen Ver- 
fahren erzielbaren Vorteile wird zunachst angenommen, da£ 
sich n Clients auf s Teilnetze verteilen. Ferner wird ange- 
nommen, daS aus jedem dieser s Teilnetze wenigstens ein Cli- 
ent versuchen wird, die Verfttgbarkeit des Servers abzufragen. 
10 Jeder dieser Clienst wiirde dann wiederum die ubrigen Clients 
innerhalb seines Teilnetzes mittels einer Multicast-Meldung 
ttber die Serververfiigbarkeit informieren. Unter idealisierten 
Bedingungen wiirde die Anzahl der durch den Server zu bearbei- 
tenden Verftigbarkeitsanf ragen der Anzahl s der Teilnetze ent- 
15 sprechen. Zusatzlich ist noch zu berucksichtigen, da£ die 

Multicast-Meldungen in den Teilnetzen eine Verlustrate v zwi- 
schen 0 und 100 Prozent aufweisen konnen. Damit ist die An- 
zahl v c von Clients pro Teilnetz, die von einer Multicast- 
Meldung nicht erreicht werden und somit selber eine Verftig- 
barkeitsanf rage an den Server senden abhangig von der Ver- 
lustrate v der Multicast-Meldungen: 



20 



30 



• Die Gesamtzahl v c a11 aller Clients, die unter dieser Voraus- 
setzung tatsachlich eine Verftigbarkeitsanf rage an den Server 
richten last sich damit wie folgt abschatzen: 

vf =j'y(--l)+i = vn-vi + j = vB+j(l-v) . 
s 



Unter diesen Annahmen kann das Zeitintervall t r zwischen zwei 
an den Server gerichteten Verfttgbarkeitsanfragen wie folgt 
berechnet werden: 

60* 



t r (a,n,s,v) = 



a-(yn + sQ.-vy) 



35 



Anhand eines Zahlenbeispiels wird die Belastung des Servers 
durch Verfttgbarkeitsanfragen bei bisher gangigen Keep-Alive- 
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Tests der Belastung des Servers entsprechend dem hier vorge- 
schlagenen Verfahrens gegentiber gestellt. Bei einer Anf rage- 
rate von a=3 Verftigbarkeitsanf ragen pro Minute und n=1000 
Clients gilt fur das Zeitintervall t r zwischen zwei Verfiig- 
barkeitsanf ragen : 

6O5 20s 



f r (a = 3,n = 1000,^v) = 



3-(v-1000 + s(l-v)) 1000-v + s(l~v) 



Typische Werte ftir die Verlustrate v liegen deutlich unter 
100 Prozent. Mit den obigen Werten fur die Anfragerate a, die 
Anzahl n der Clients und s=10 Teilnetzen ergeben sich in Ab- 
hangigkeit von der Verlustrate v die folgenden Ef f izienzstei- 
gerungen cUf f in Prozent bezogen auf die gangigen Keep-Alive- 
Tests mit einem Zeitintervall t r = 20 ms zwischen zwei Ver- 
ftigbarkeitsanf ragen : 



V 


0.0 


0.1 


0.2 


0.5 


0.8 


trims] 


2000 


183 


96 


40 


25 


cUff[%] 


9900 


815 


380 


100 


25 



Bei einer Verlustrate v = 20 % betragt die mittlere Zeit t r 
zwischen zwei durch den Server zu bearbeitende Verftigbar- 
keitsanf ragen beispielsweise ca. 96 ms. Dies entspricht einer 
Ef f izienzsteigerung deff = 380 % im Vergleich zu bisher gangi- 
gen Keep-Alive-Tests. 

Insgesamt ist f estzustellen, daS bei dem hier vorgeschlagenen 
Verfahren zur Uberpriifung der Serververftigbarkeit die Bela- 
stung des Servers durch eine Beantwortung von Verftigbarkeits- 
anf ragen deutlich sinkt, ohne dafi dies zu einer signif ikanten 
Erhdhung der Zeit fiihrt, bis den Clients die Nichtverfugbar- 
keit des Servers bekannt wird. AuSerdem sind zur Implement ie- 
rung des hier vorgeschlagenen Verfahrens lediglich auf Seiten 
der Clients Anderungen notwendig. Die bisherige Vorgehenswei- 
se zur Bearbeitung von Verftigbarkeitsanf ragen kann auf Ser- 
verseite beibehalten werden und erfordert damit keine weite- 
ren Aufwendungen. 
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Bei dem in Figur 3 dargestellten Verfahren wird zusatzlich 
die Verfugbarkeit von Clients durch einen Server uberpriift. 
Dies bedeutet, daS ein Server auch uber die Verfugbarkeit von 
Clients informiert ist, die lediglich von einen anderen Cli- 
ent per Multicast-Meldung tiber die Verfugbarkeit des Servers 
informiert werden und nicht selber Keep-Alive-Anf ragen direkt 
an den Server richten. Zunachst startet jeder Client einen 
erster Timer (Timer 1) (Schritt 301) und tiberpruft, ob eine 
Multicast- Sammelanf rage empfangen wurde (Schritt 302) . Eine 
Multicast-Sammelanfrage kann von einem Client als Zeichen da- 
far ausgesendet werden, daS dieser Client einen Sammel-Keep- 
Alive-Test mit einem Server durchftihreh mochte, und daS die- 
ser Client daftir die Keep-Alive-Daten anderer Clients beno- 
tigt. 

Der Zustand des ersten Timers wird fortlaufend durch den je- 
weiligen Client uberpriift (Schritt 303) . Sollte der erste Ti- 
mer noch nicht abgelaufen und keine Multicast-Sammelanf rage 
eingegangen sein, so wird der Empfang einer Multicast-Sammel- 
anf rage weiter uberwacht. 1st der erste Timer abgelaufen und 
keine Multicast-Sammelanf rage empfangen worden, so uberniramt 
der jeweilige Client die Aufgabe, selber eine Multicast- 
Sammelanf rage an einen ausgewahlten Server zu richten. Dazu 
startet der jeweilige anfragende Client einen zweiten Timer 
(Timer 2) (Schritt 304) und ubermittelt eine Multicast- 
Sammelanf rage an vorgebbare weitere Clients (Schritt 305) . 
Nachfolgend tiberpruft der jeweilige anfragende Client, ob die 
Multicast-Sammelanfrage von den vorgebbaren weiteren Clients 
beantwortet wurde (Schritt 306) , und ob der zweite Timer ab- 
gelaufen ist (Schritt 307) . Sollte der zweite Timer noch 
nicht abgelaufen und keine Antwort auf die Multicast- 
Sammelanfrage eingegangen sein, so wird der Empfang einer 
Antwort auf die Multicast-Sammelanfrage weiter tiberwacht. 

Nach Ablauf des zweiten Timers startet der jeweilige anfra- 
gende Client einen dritten Timer (Timer 3) (Schritt 308) und 
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sendet eine Sammel-Verfugbarkeitsanf rage an den ausgewahlten 
Server (Schritt 309) . Die Sammel-Verfugbarkeitsanf rage umfafct 
Daten des jeweiligen anfragenden Clients und derjenigen vor- 
gebbaren weiteren Clients, die bis zum Ablauf des zweiten Ti- 
5 mers auf die Multicast-Sammelanf rage des jeweiligen anfragen- 
den Clients geantwortet haben. Nachfolgend uberpruft der je- 
weilige anfragende Client, ob der ausgewahlte Server Verfug- 
barkeit signalisiert hat (Schritt 310), und ob der dritte Ti- 
mer abgelaufen ist (Schritt 311) . Sollte der dritte Timer 
10 noch nicht abgelaufen und keine Antwort auf die Sammel-Ver- 

• ftigbarkeitsanfrage eingegangen sein, so wird der Empfang ei- 
ner Antwort auf die Sammel-Verfugbarkeitsanf rage weiter tiber- 
wacht . 

15 Hat der ausgewahlte Server seine Verfugbarkeit dem jeweiligen 
anfragenden Client signalisiert, so tibermittelt der jeweilige 
anfragende Client eine positive Multicast-Verfiigbarkeitsmel- 
dung an die vorgebbaren weiteren Clients (Schritt 312) . Soll- 
te der ausgewahlte Server seine Nichtverfugbarkeit signali- 

20 siert oder bis zum Ablauf des dritten Timers keine Antwort 

auf die Sammel-Verftigbarkeitsanf rage gesendet haben, so uber- 
mittelt der jeweilige anfragende Client eine negative Multi- 
cast-Verftigbarkeitsmeldung an die vorgebbaren weiteren Cli- 
ents (Schritt 313) • 

Vorgebbare weitere Clients, die entsprechend der Uberprtifung 
in Schritt 302 eine Multicast-Sammelanf rage empfangen haben, 
tibermitteln ihre Keep-Alive-Daten an den jeweiligen anfragen- 
den Client (Schritt 314), deren Empfang der jeweilige anfra- 

30 gende Client entsprechend Schritt 306 tiberprttft. Nachfolgend 
starten die vorgebbaren weiteren Clients einen vierten Timer 
(Timer 4) (Schritt 315) und uberprufen, ob eine positive oder 
negative Multicast-Verftigbarkeitsmeldung des jeweiligen an- 
fragenden Clients empfangen wurde (Schritt 316) , und ob der 

35 vierte Timer abgelaufen ist (Schritt 317) . Bei Empfang einer 
Multicast-Verfugbarkeitsmeldung des jeweiligen anfragenden 
Clients wird der erste Timer zuruckgesetzt (Schritt 318), so 
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da£ die vorgebbaren weiteren Clients fur eine durch den Ab- 
lauf des ersten Timers bestimmte Zeitdauer keine Verfugbara- 
keitsanfragen an den ausgewahlten Server richten. 

5 Solange der vierte Timer nicht abgelaufen ist, warten die 
vorgebbaren weiteren Clients auf eine Multicast-Verfugbar- 
keitsmeldung des jeweiligen anfragenden Clients. Sollte dies 
nicht vor Ablauf des vierten Timers geschehen, ubernimmt der 
jeweilige Client nun selbst eine Rolle als Steller einer Sam- 
10 mel-Verftigbarkeitsanfrage entsprechend den Schritten 304 bis 

•313, sofern der erste Timer abgelaufen ist bzw. vor seinem 
Ablauf keine weitere Multicast-Sammelanf rage eingeht. 

Die Anwendung der vorliegenden Erfindung ist nicht auf das 
15 hier beschriebene Ausfuhrungsbei spiel beschrankt. 



200307837 



14 

Patentanspruche 

1. Verfahren zur Uberprtifung der Verftigbarkeit eines Servers, 
bei dem 

- eine Verftigbarkeitsanf rage von einem Client an einen Ser- 
ver ubermittelt wird, 

- die Verfxigbarkeitsanfrage bei Verftigbarkeit des Servers 
durch eine vom Server an den Client ubermittelte Bestati- 
gungsmeldung beantwortet wird, 

dadurch gekennzeichnet , daS der Client eine Meldung uber die 
Verfugbarkeit des Servers an weitere Clients ubermittelt, die 
daraufhin jeweils ein Ubermitteln einer Verfxigbarkeitsanfrage 
an den Server zumindest fur ein vorgebbares Zeitintervall un- 
terbinden. 

2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, dafi Daten zwischen dem Server und den 
Clients mittels verbindungsloser Vermittlungssteuerung tiber- 
mittelt we r den . 

3 . Verfahren nach einem der Anspriiche 1 oder 2 , 

dadurch gekennzeichnet, daS die Meldung uber die Verftigbar- 
keit des Servers an die vorgebbaren weiteren Clients mittels 
Multicast ubermittelt wird. 

4. Verfahren nach einem der Anspriiche 1 bis 3, 

dadurch gekennzeichnet, dag der Client nur vorgebbare weitere 
Clients innerhalb desselben Teilnetzes \iber die Verfugbarkeit 
des Servers informiert. 

5 . Verfahren nach einem der Anspriiche 1 bis 4 , 
dadurch gekennzeichnet, dafi der Client zu durch eine 
Zeitsteuerung vorgegebenen Zeitpunkten Verftigbarkeitsanf ragen 
ausfiihrt . 
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6. Verfahren nach Anspruch 5, 

dadurch gekennzeichnet, daS jeweils ein Zahler einer 
Zeitsteuerung, die einem vorgebbaren weiteren Client zugeord- 
net ist und Verftigbarkeitsanfragen veranlafit, bei Erapfang ei- 
ner Meldung iiber die Verftigbarkeit des Servers auf einen vor- 
gebbaren Wert zurtickgesetzt wird. 

7. Steuerungsprogramm, das in einen Arbeitsspeicher eines 
Clients ladbar ist und zumindest einen Codeabschnitt auf- 
weist, bei dessen Ausfuhrung 

- eine Verftigbarkeitsanfrage von dem Client an einen Server 
tibermittelt wird, 

- ein Empfang einer die Verftigbarkeitsanfrage bei Verftigbar- 
keit des Servers beantwortenden Bestatigungsmeldung tiber- 
wacht wird, 

- eine Meldung iiber die Verftigbarkeit des Servers an weitere 
Clients tibermittelt wird, 

- ein Empfang einer Meldung eines vorgebbaren weiteren Cli- 
ents iiber die Verfugbarkeit des Servers tiberwacht und ein 
Ubermitteln einer Verftigbarkeitsanfrage an den Server zu- 
mindest fur ein vorgebbares Zeitintervall bei Empfang ei- 
ner solchen Meldung unterbunden wird, 

wenn das Steuerungsprogramm in dem Client ablauft. 

8. Client fur ein verbindungslose Dienste bereitstellendes 
Kommunikationsnetz mit 

- einer Einrichtung zum Ubermitteln einer Verftigbarkeitsan- 
frage an einen Server, 

- einer Einrichtung zur Uberwachung eines Empfangs einer die 
Verftigbarkeitsanfrage bei Verftigbarkeit des Servers beant- 
wortenden Bestatigungsmeldung, 

- einer Einrichtung zur ubermittlung einer Meldung iiber die 
Verftigbarkeit des Servers an weitere Clients, 

- einer Einrichtung zur Uberwachung. eines Empfangs einer 
Meldung eines vorgebbaren weiteren Clients iiber die Ver- 
ftigbarkeit des Servers und zum Unterbinden eines Ubermit- 
telns einer Verftigbarkeitsanfrage an den Server zumindest 
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fur ein vorgebbares Zeitintervall bei Empfang einer sol- 
chen Meldung. 
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Zusammenf as sung 

Uberprufung der Verfugbarkeit eines Servers 

Zur Uberprtifung der Verfugbarkeit eines Servers wird eine 
Verfugbarkeitsanfrage von einem Client an einen Server uber- 
mittelt. Die Verfugbarkeitsanfrage wird bei Verfugbarkeit des 
Servers durch eine vom Server an den Client libermittelte Be- 
st at igungsmeldung beantwortet. Der Client ubermittelt eine 
Meldung uber die Verfugbarkeit des Servers an weitere Cli- 
ents, die daraufhin jeweils ein Ubermitteln einer Verfugbar- 
keitsanfrage an den Server zumindest fur ein vorgebbares Zei- 
tintervall unterbinden. 
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